(#16429) Relpaths #122
(#16429) Relpaths #122
Conversation
These links work when puppet-dashboard is at the top level because browsers treat /../ as equivalent to /.
With corresponding generated changes in application.css
This gets the path right even when the app is hosted at a sub-URI. A basic test of the page looks for the link.
|
I just added a fourth for the radiator view, which I had missed initially. |
|
@djmitche I need to verify that all the tests pass with these changes. In the interim, can you give me a bit more justification on the problem this is actually solving? Thanks! |
|
They fix (partially) the case where you're running the dashboard at a base URL other than |
|
Ok I re-read the changes. In particular I thought you changed from Other than that, I'm comfortable with this PR. |
|
Those that I changed, I observed doing the wrong thing in a running dashboard, so I tend to think not. But I can't prove it beyond this statement. |
|
@puppetlabs Do you have any plugins that are extending the Dashboard routes to add third-level deep URL paths? If not, I'd like to merge this in. |
|
This will still work with third-level-deep URL paths. Paths in CSS are relative to the CSS file, not All paths generated in Ruby use the controller to generate the path, so they'll be absolute and correct. |
|
@djmitche Oh. I'm a doofus. You're right, the images are relative to the css file's url, not to the current page url. Merging now! |
Two of these fixes are simple changes to the CSS.
The third is a code change, but relatively minor.
I added a test for the code change, but I don't see an easy way to test that it gets the right path even at a sub-URI. Still, this shows that the code is executed and produces the correct result in at least one condition.